ui: list resources of project-owned instances outside project view - #14581

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 16.47%. Comparing base (e6f193d) to head (d85ab4e).

@@             Coverage Diff              @@
##               4.20   #14581      +/-   ##
============================================
+ Coverage     16.45%   16.47%   +0.01%     
- Complexity    13710    13714       +4     
============================================
  Files          5669     5669              
  Lines        501734   501737       +3     
  Branches      60961    60967       +6     
============================================
+ Hits          82584    82655      +71     
+ Misses       409895   409819      -76     
- Partials       9255     9263       +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@blueorangutan package

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

@1fanwang, please review my version of your fix here.

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19901

@blueorangutan test

@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

[SF] Trillian test result (tid-17490)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 54797 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr14581-t17490-kvm-ol8.zip
Smoke tests completed. 141 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Unsure if it's something wrong on my setup but I cannot see templates on the "Default view" anymore without the following patch.

diff --git a/ui/src/views/compute/DeployVM.vue b/ui/src/views/compute/DeployVM.vue
index 72cb74399d..dba8501023 100644
--- a/ui/src/views/compute/DeployVM.vue
+++ b/ui/src/views/compute/DeployVM.vue
@@ -1007,7 +1007,7 @@ export default {
         groups: false
       },
       owner: {
-        projectid: store.getters.project?.id,
+        projectid: store.getters.project?.id || null,
         domainid: store.getters.project?.id ? null : store.getters.userInfo.domainid,
         account: store.getters.project?.id ? null : store.getters.userInfo.account
       },

The rest seems to work. I can see the resources from the default view while they are owned by a project.

@bddvlpr , thanks for the finding, I'll look into that and update.

@bddvlpr, it wasn't you/your env, but a conflict with an old PR. I added a fix. hope all works now.

@blueorangutan ui

@DaanHoogland a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: ✔️
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/14581 (QA-JID-1012)

Good morning, @DaanHoogland,

Thank you for the fix. Apologies for taking so long to test; I first tried to (remotely through IPMI) install a new physical development area, but had issues compiling the code (especially failing tests such as LDAP, though unrelated to this incident). To avoid delaying the testing above, I ran it in the provided environment.

With the provided QA link above, I was able to test this.
The behaviour was as expected, and I was able to add a new network to a project and add multiple NICs (guest networks belonging to the same project) to the VM.

I can also confirm that it fixes #14572.

@nvazquez

With the provided QA link above, I was able to test this. The behaviour was as expected, and I was able to add a new network to a project and add multiple NICs (guest networks belonging to the same project) to the VM.

I can also confirm that it fixes #14572.

can you review?

Good morning, @DaanHoogland,

After reviewing your proposed code changes (apologies; I have some coding experience but am not a coder by trade), I noticed a potential issue. I have made the following observations:

Observation 1

1. When a VM is created and owned by a user.
2. An Instance Snapshot is made.
3. The user can view, revert and manage the snapshot.
4. The ownership of the VM is changed to a project.
5. The user’s Snapshot is still present, but the user (correctly?) remains its owner.
6. Another Instance Snapshot is taken, and the project becomes its owner… however, the second (project) instance snapshot is not displayed in the normal view
7. The Instance Snapshot is correctly visible in the Compute -> Instance Snapshots view when the view Project toggle is enabled.

Suggestion: The above scenario does not lead to too many functional issues, and perhaps adding the tests you ran to include, e.g., project.id ? project : {}, could be an "easy/quick" fix to display the normal Instance Snapshots view as well.

However, the following is a more "drastic" potential issue that is present/introduced.

Observation 2:

A user-owned instance with a Volume snapshot exists.
When attempting to change the VM owner to a project, the process fails because a user-owned volume snapshot exists.
When deleting the snapshot(s), the VM ownership can be changed.

Suggestion: Consider changing the volumes and their snapshots’ ownership before changing the instance’s ownership. However, I am not sure if it would be possible without a chase condition. Also, I am not sure if this (changing all the ownerships of the VM and its related objects) is the expected behaviour. Should snapshot ownership ever be transferred between users and projects? If not, then this "bug" will persist.

On a side note, the proposed fix also fixes a possibly unknown issue. Without the fix, it is not possible to make a volume snapshot of a project-owned volume in the UI. When a project-owned VM is viewed and a volume snapshot is attempted, the volume dropdown list is empty. When attempting to perform the action from Storage -> Volumes -> selecting the specific volume and then clicking on Snapshot, it produced an error: “Failed to create Snapshot due to an internal error creating Snapshot for volume”.

@1fanwang, please review my version of your fix here.

The VolumesTab change and its new tests match mine apart from the API helper name that 4.20 uses. I did not review the other files in this pull request. I agree with closing the 4.22 pull request in favour of this one, so I have closed it.

Thanks @vanecka,

Observation 1: same cause as the rest of this PR: the Instance Snapshots tab (and the Backups tab) on the instance page didn't send the instance's project. Both now do, so a project-owned instance's snapshots and backups show up outside the project view as well. Note that a snapshot taken while the instance was still yours stays owned by you, so it shows under Compute → Instance Snapshots in the Default view rather than on the (now project-owned) instance's tab.

Observation 2: that's deliberate server-side behaviour: assigning an instance to another owner is refused while its volumes have snapshots ("Detach volume or remove snapshots for the volume before assigning VM to another user"). Whether snapshots should move along with the instance is a fair question, but it's a backend change outside the scope of this UI fix. Could you open a separate issue for it?
On this, I would refuse it, because a snapshot is a first class citizen in cloudstack with a lifecycle and owner not tightly coupled to the volume/instance it is a snapshot from.

On the side note: nice and bummer ;). Glad the snapshot dialog works now. The "internal error creating Snapshot" issue is worth its own issue I think. I would like not to creep the scope of this PR for it. Can you reproduce it and add some logging information to the issue, if you create it?

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud